\latexhtml{\newcommand{\path}[1]{{\small {\tt #1}}}}{\newcommand{\path}[1]{{\tt #1}}}
-
\begin{document}
% TITLE PAGE
\vfill
\vfill
\begin{tabular}{l}
-{\Huge \bf Users' manual} \\[4mm]
-{\huge Xen v2.0 for x86} \\[80mm]
+{\Huge \bf Users' Manual} \\[4mm]
+{\huge Xen v3.0} \\[80mm]
-{\Large Xen is Copyright (c) 2002-2004, The Xen Team} \\[3mm]
+{\Large Xen is Copyright (c) 2002-2005, The Xen Team} \\[3mm]
{\Large University of Cambridge, UK} \\[20mm]
\end{tabular}
\end{center}
-{\bf
-DISCLAIMER: This documentation is currently under active development
-and as such there may be mistakes and omissions --- watch out for
-these and please report any you find to the developer's mailing list.
-Contributions of material, suggestions and corrections are welcome.
-}
+{\bf DISCLAIMER: This documentation is currently under active
+ development and as such there may be mistakes and omissions ---
+ watch out for these and please report any you find to the
+ developers' mailing list. Contributions of material, suggestions
+ and corrections are welcome.}
\vfill
\cleardoublepage
+
% TABLE OF CONTENTS
\pagestyle{plain}
\pagenumbering{roman}
\tableofcontents }
\cleardoublepage
+
% PREPARE FOR MAIN TEXT
\pagenumbering{arabic}
\raggedbottom
%% Chapter Installation moved to installation.tex
\include{src/user/installation}
-%% Chapter Starting Additional Domains moved to start_addl_dom.tex
+%% Chapter Starting Additional Domains moved to start_addl_dom.tex
\include{src/user/start_addl_dom}
%% Chapter Domain Management Tools moved to domain_mgmt.tex
software (or the documentation) should be sent to the Xen developers'
mailing list (address below).
+
\section{Other Documentation}
For developers interested in porting operating systems to Xen, the
-{\em Xen Interface Manual} is distributed in the \path{docs/}
-directory of the Xen source distribution.
+\emph{Xen Interface Manual} is distributed in the \path{docs/}
+directory of the Xen source distribution.
-%Various HOWTOs are available in \path{docs/HOWTOS} but this content is
-%being integrated into this manual.
+% Various HOWTOs are available in \path{docs/HOWTOS} but this content
+% is being integrated into this manual.
\section{Online References}
The official Xen web site is found at:
-\begin{quote}
-{\tt http://www.cl.cam.ac.uk/netos/xen/}
+\begin{quote} {\tt http://www.cl.cam.ac.uk/netos/xen/}
\end{quote}
-This contains links to the latest versions of all on-line
-documentation (including the lateset version of the FAQ).
+This contains links to the latest versions of all online
+documentation, including the latest version of the FAQ.
\section{Mailing Lists}
\begin{description}
\item[xen-devel@lists.xensource.com] Used for development
-discussions and bug reports. Subscribe at: \\
-{\small {\tt http://lists.xensource.com/xen-devel}}
+ discussions and bug reports. Subscribe at: \\
+ {\small {\tt http://lists.xensource.com/xen-devel}}
\item[xen-users@lists.xensource.com] Used for installation and usage
-discussions and requests for help. Subscribe at: \\
-{\small {\tt http://lists.xensource.com/xen-users}}
+ discussions and requests for help. Subscribe at: \\
+ {\small {\tt http://lists.xensource.com/xen-users}}
\item[xen-announce@lists.xensource.com] Used for announcements only.
-Subscribe at: \\
-{\small {\tt http://lists.xensource.com/xen-announce}}
-\item[xen-changelog@lists.xensource.com] Changelog feed
-from the unstable and 2.0 trees - developer oriented. Subscribe at: \\
-{\small {\tt http://lists.xensource.com/xen-changelog}}
+ Subscribe at: \\
+ {\small {\tt http://lists.xensource.com/xen-announce}}
+\item[xen-changelog@lists.xensource.com] Changelog feed
+ from the unstable and 2.0 trees - developer oriented. Subscribe at: \\
+ {\small {\tt http://lists.xensource.com/xen-changelog}}
\end{description}
%% Chapter Installing Xen on Red Hat moved to redhat.tex
\include{src/user/redhat}
-
%% Chapter Glossary of Terms moved to glossary.tex
\include{src/user/glossary}
+
\end{document}
%% # import xenctl.utils
%% # help(xenctl.utils)
-%% You can use these modules to write your own custom scripts or you can
-%% customise the scripts supplied in the Xen distribution.
+%% You can use these modules to write your own custom scripts or you
+%% can customise the scripts supplied in the Xen distribution.
% Explain about AGP GART
-%% If you're not intending to configure the new domain with an IP address
-%% on your LAN, then you'll probably want to use NAT. The
-%% 'xen_nat_enable' installs a few useful iptables rules into domain0 to
-%% enable NAT. [NB: We plan to support RSIP in future]
-
+%% If you're not intending to configure the new domain with an IP
+%% address on your LAN, then you'll probably want to use NAT. The
+%% 'xen_nat_enable' installs a few useful iptables rules into domain0
+%% to enable NAT. [NB: We plan to support RSIP in future]
%% Installing the file systems from the CD
%% =======================================
-%% If you haven't got an existing Linux installation onto which you can
-%% just drop down the Xen and Xenlinux images, then the file systems on
-%% the CD provide a quick way of doing an install. However, you would be
-%% better off in the long run doing a proper install of your preferred
-%% distro and installing Xen onto that, rather than just doing the hack
-%% described below:
-
-%% Choose one or two partitions, depending on whether you want a separate
-%% /usr or not. Make file systems on it/them e.g.:
-%% mkfs -t ext3 /dev/hda3
-%% [or mkfs -t ext2 /dev/hda3 && tune2fs -j /dev/hda3 if using an old
+%% If you haven't got an existing Linux installation onto which you
+%% can just drop down the Xen and Xenlinux images, then the file
+%% systems on the CD provide a quick way of doing an install. However,
+%% you would be better off in the long run doing a proper install of
+%% your preferred distro and installing Xen onto that, rather than
+%% just doing the hack described below:
+
+%% Choose one or two partitions, depending on whether you want a
+%% separate /usr or not. Make file systems on it/them e.g.:
+%% mkfs -t ext3 /dev/hda3
+%% [or mkfs -t ext2 /dev/hda3 && tune2fs -j /dev/hda3 if using an old
%% version of mkfs]
%% Next, mount the file system(s) e.g.:
%% configuration. Changing the password file (etc/shadow) is probably a
%% good idea too.
-%% To install the usr file system, copy the file system from CD on /usr,
-%% though leaving out the "XenDemoCD" and "boot" directories:
-%% cd /usr && cp -a X11R6 etc java libexec root src bin dict kerberos local sbin tmp doc include lib man share /mnt/usr
+%% To install the usr file system, copy the file system from CD on
+%% /usr, though leaving out the "XenDemoCD" and "boot" directories:
+%% cd /usr && cp -a X11R6 etc java libexec root src bin dict kerberos
+%% local sbin tmp doc include lib man share /mnt/usr
%% If you intend to boot off these file systems (i.e. use them for
-%% domain 0), then you probably want to copy the /usr/boot directory on
-%% the cd over the top of the current symlink to /boot on your root
-%% filesystem (after deleting the current symlink) i.e.:
+%% domain 0), then you probably want to copy the /usr/boot
+%% directory on the cd over the top of the current symlink to /boot
+%% on your root filesystem (after deleting the current symlink)
+%% i.e.:
%% cd /mnt/root ; rm boot ; cp -a /usr/boot .
required if you wish to build from source.
\begin{itemize}
\item A working Linux distribution using the GRUB bootloader and
- running on a P6-class (or newer) CPU.
+ running on a P6-class or newer CPU\@.
\item [$\dag$] The \path{iproute2} package.
\item [$\dag$] The Linux bridge-utils\footnote{Available from {\tt
http://bridge.sourceforge.net}} (e.g., \path{/sbin/brctl})
alternatively it can be installed by running `{\sl make
install-twisted}' in the root of the Xen source tree.
\item [$*$] Build tools (gcc v3.2.x or v3.3.x, binutils, GNU make).
-\item [$*$] Development installation of libcurl (e.g., libcurl-devel)
-\item [$*$] Development installation of zlib (e.g., zlib-dev).
-\item [$*$] Development installation of Python v2.2 or later (e.g.,
+\item [$*$] Development installation of libcurl (e.g.,\ libcurl-devel).
+\item [$*$] Development installation of zlib (e.g.,\ zlib-dev).
+\item [$*$] Development installation of Python v2.2 or later (e.g.,\
python-dev).
\item [$*$] \LaTeX\ and transfig are required to build the
documentation.
\end{itemize}
-Once you have satisfied the relevant prerequisites, you can now
-install either a binary or source distribution of Xen.
+Once you have satisfied these prerequisites, you can now install
+either a binary or source distribution of Xen.
\section{Installing from Binary Tarball}
Pre-built tarballs are available for download from the Xen download
-page
-\begin{quote} {\tt http://xen.sf.net}
+page:
+\begin{quote} {\tt http://www.xensource.com/downloads/}
\end{quote}
Once you've downloaded the tarball, simply unpack and install:
\begin{verbatim}
-# tar zxvf xen-2.0-install.tgz
-# cd xen-2.0-install
+# tar zxvf xen-3.0-install.tgz
+# cd xen-3.0-install
# sh ./install.sh
\end{verbatim}
\section{Installing from Source}
-This section describes how to obtain, build, and install Xen from
+This section describes how to obtain, build and install Xen from
source.
\subsection{Obtaining the Source}
-The Xen source tree is available as either a compressed source tar
-ball or as a clone of our master BitKeeper repository.
+The Xen source tree is available as either a compressed source tarball
+or as a clone of our master Mercurial repository.
\begin{description}
\item[Obtaining the Source Tarball]\mbox{} \\
- Stable versions (and daily snapshots) of the Xen source tree are
- available as compressed tarballs from the Xen download page
- \begin{quote} {\tt http://xen.sf.net}
+ Stable versions and daily snapshots of the Xen source tree are
+ available from the Xen download page:
+ \begin{quote} {\tt \tt http://www.xensource.com/downloads/}
+ \end{quote}
+\item[Obtaining the source via Mercurial]\mbox{} \\
+ The source tree may also be obtained via the public Mercurial
+ repository hosted at:
+ \begin{quote}{\tt http://xenbits.xensource.com}.
+ \end{quote} See the instructions and the Getting Started Guide
+ referenced at:
+ \begin{quote}
+ {\tt http://www.xensource.com/downloads/}.
\end{quote}
-
-\item[Using BitKeeper]\mbox{} \\
- If you wish to install Xen from a clone of our latest BitKeeper
- repository then you will need to install the BitKeeper tools.
- Download instructions for BitKeeper can be obtained by filling out
- the form at:
- \begin{quote} {\tt http://www.bitmover.com/cgi-bin/download.cgi}
-\end{quote}
-The public master BK repository for the 2.0 release lives at:
-\begin{quote} {\tt bk://xen.bkbits.net/xen-2.0.bk}
-\end{quote}
-You can use BitKeeper to download it and keep it updated with the
-latest features and fixes.
-
-Change to the directory in which you want to put the source code, then
-run:
-\begin{verbatim}
-# bk clone bk://xen.bkbits.net/xen-2.0.bk
-\end{verbatim}
-
-Under your current directory, a new directory named \path{xen-2.0.bk}
-has been created, which contains all the source code for Xen, the OS
-ports, and the control tools. You can update your repository with the
-latest changes at any time by running:
-\begin{verbatim}
-# cd xen-2.0.bk # to change into the local repository
-# bk pull # to update the repository
-\end{verbatim}
\end{description}
% \section{The distribution}
\subsection{Building from Source}
-The top-level Xen Makefile includes a target `world' that will do the
+The top-level Xen Makefile includes a target ``world'' that will do the
following:
\begin{itemize}
\item Build the control tools, including \xend.
\item Download (if necessary) and unpack the Linux 2.6 source code,
and patch it for use with Xen.
-\item Build a Linux kernel to use in domain 0 and a smaller
+\item Build a Linux kernel to use in domain~0 and a smaller
unprivileged kernel, which can optionally be used for unprivileged
virtual machines.
\end{itemize}
After the build has completed you should have a top-level directory
-called \path{dist/} in which all resulting targets will be placed; of
-particular interest are the two kernels XenLinux kernel images, one
-with a `-xen0' extension which contains hardware device drivers and
-drivers for Xen's virtual devices, and one with a `-xenU' extension
-that just contains the virtual ones. These are found in
+called \path{dist/} in which all resulting targets will be placed. Of
+particular interest are the two XenLinux kernel images, one with a
+``-xen0'' extension which contains hardware device drivers and drivers
+for Xen's virtual devices, and one with a ``-xenU'' extension that
+just contains the virtual ones. These are found in
\path{dist/install/boot/} along with the image for Xen itself and the
configuration files used during the build.
\begin{quote}
\begin{verbatim}
# make netbsd20
-\end{verbatim}
-\end{quote}
+\end{verbatim}\end{quote}
NetBSD port is built using a snapshot of the netbsd-2-0 cvs branch.
-The snapshot is downloaded as part of the build process, if it is not
+The snapshot is downloaded as part of the build process if it is not
yet present in the \path{NETBSD\_SRC\_PATH} search path. The build
-process also downloads a toolchain which includes all the tools
+process also downloads a toolchain which includes all of the tools
necessary to build the NetBSD kernel under Linux.
-To customize further the set of kernels built you need to edit the
-top-level Makefile. Look for the line:
-
+To customize the set of kernels built you need to edit the top-level
+Makefile. Look for the line:
\begin{quote}
\begin{verbatim}
KERNELS ?= mk.linux-2.6-xen0 mk.linux-2.6-xenU
%% After untaring the pristine kernel tree, the makefile uses the {\tt
%% mkbuildtree} script to add the Xen patches to the kernel.
-
%% \framebox{\parbox{5in}{
%% {\bf Distro specific:} \\
%% {\it Gentoo} --- if not using udev (most installations,
% If you have an SMP machine you may wish to give the {\tt '-j4'}
% argument to make to get a parallel build.
-If you wish to build a customized XenLinux kernel (e.g. to support
+If you wish to build a customized XenLinux kernel (e.g.\ to support
additional devices or enable distribution-required features), you can
use the standard Linux configuration mechanisms, specifying that the
architecture being built for is \path{xen}, e.g:
\end{quote}
You can also copy an existing Linux configuration (\path{.config})
-into \path{linux-2.6.11-xen0} and execute:
+into e.g.\ \path{linux-2.6.11-xen0} and execute:
\begin{quote}
\begin{verbatim}
# make ARCH=xen oldconfig
\end{verbatim}
\end{quote}
-You may be prompted with some Xen-specific options; we advise
+You may be prompted with some Xen-specific options. We advise
accepting the defaults for these options.
-Note that the only difference between the two types of Linux kernel
-that are built is the configuration file used for each. The `U'
+Note that the only difference between the two types of Linux kernels
+that are built is the configuration file used for each. The ``U''
suffixed (unprivileged) versions don't contain any of the physical
hardware device drivers, leading to a 30\% reduction in size; hence
-you may prefer these for your non-privileged domains. The `0'
+you may prefer these for your non-privileged domains. The ``0''
suffixed privileged versions can be used to boot the system, as well
as in driver domains and unprivileged domains.
The \path{dist/install/boot} directory will also contain the config
files used for building the XenLinux kernels, and also versions of Xen
-and XenLinux kernels that contain debug symbols (\path{xen-syms-2.0.6}
-and \path{vmlinux-syms-2.6.11.11-xen0}) which are essential for
-interpreting crash dumps. Retain these files as the developers may
-wish to see them if you post on the mailing list.
+and XenLinux kernels that contain debug symbols such as
+(\path{xen-syms-2.0.6} and \path{vmlinux-syms-2.6.11.11-xen0}) which
+are essential for interpreting crash dumps. Retain these files as the
+developers may wish to see them if you post on the mailing list.
\section{Configuration}
{\small
\begin{verbatim}
-title Xen 2.0 / XenLinux 2.6
- kernel /boot/xen-2.0.gz dom0_mem=131072
+title Xen 3.0 / XenLinux 2.6
+ kernel /boot/xen-3.0.gz dom0_mem=131072
module /boot/vmlinuz-2.6-xen0 root=/dev/sda4 ro console=tty0
\end{verbatim}
}
The kernel line tells GRUB where to find Xen itself and what boot
-parameters should be passed to it (in this case, setting domain 0's
+parameters should be passed to it (in this case, setting the domain~0
memory allocation in kilobytes and the settings for the serial port).
For more details on the various Xen boot parameters see
Section~\ref{s:xboot}.
The module line of the configuration describes the location of the
XenLinux kernel that Xen should start and the parameters that should
-be passed to it (these are standard Linux parameters, identifying the
+be passed to it. Tthese are standard Linux parameters, identifying the
root device and specifying it be initially mounted read only and
-instructing that console output be sent to the screen). Some
+instructing that console output be sent to the screen. Some
distributions such as SuSE do not require the \path{ro} parameter.
%% \framebox{\parbox{5in}{
If you want to use an initrd, just add another \path{module} line to
-the configuration, as usual:
-
+the configuration, like:
{\small
\begin{verbatim}
module /boot/my_initrd.gz
\end{verbatim}
}
-As always when installing a new kernel, it is recommended that you do
-not delete existing menu options from \path{menu.lst} --- you may want
-to boot your old Linux kernel in future, particularly if you have
-problems.
+When installing a new kernel, it is recommended that you do not delete
+existing menu options from \path{menu.lst}, as you may wish to boot
+your old Linux kernel in future, particularly if you have problems.
\subsection{Serial Console (optional)}
%% kernel /boot/xen-2.0.gz dom0_mem=131072 com1=115200,8n1
%% module /boot/vmlinuz-2.6-xen0 root=/dev/sda4 ro
-
In order to configure Xen serial console output, it is necessary to
add an boot option to your GRUB config; e.g.\ replace the above kernel
line with:
achieve this append ``\path{console=ttyS0}'' to your module line.
If you wish to be able to log in over the XenLinux serial console it
-is necessary to add a line into \path{/etc/inittab}, just as per
-regular Linux. Simply add the line:
+is necessary to add a line into \path{/etc/inittab}. Add the line:
\begin{quote} {\small {\tt c:2345:respawn:/sbin/mingetty ttyS0}}
\end{quote}
-and you should be able to log in. Note that to successfully log in as
-root over the serial line will require adding \path{ttyS0} to
-\path{/etc/securetty} in most modern distributions.
+and you should be able to log in. To successfully log in as root over
+the serial line will require adding \path{ttyS0} to
+\path{/etc/securetty} if it is not already there.
\subsection{TLS Libraries}
Users of the XenLinux 2.6 kernel should disable Thread Local Storage
-(e.g.\ by doing a \path{mv /lib/tls /lib/tls.disabled}) before
-attempting to run with a XenLinux kernel\footnote{If you boot without
+(TLS) (e.g.\ by doing a \path{mv /lib/tls /lib/tls.disabled}) before
+attempting to boot a XenLinux kernel\footnote{If you boot without
first disabling TLS, you will get a warning message during the boot
process. In this case, simply perform the rename after the machine
is up and then run \texttt{/sbin/ldconfig} to make it take effect.}.
-You can always reenable it by restoring the directory to its original
+You can always reenable TLS by restoring the directory to its original
location (i.e.\ \path{mv /lib/tls.disabled /lib/tls}).
The reason for this is that the current TLS implementation uses
performance substantially.
We hope that this issue can be resolved by working with Linux
-distribution vendors to implement a minor backward-compatible change
+distributions to implement a minor backward-compatible change
to the TLS library.
\section{Booting Xen}
It should now be possible to restart the system and use Xen. Reboot
-as usual but choose the new Xen option when the Grub screen appears.
+and choose the new Xen option when the Grub screen appears.
What follows should look much like a conventional Linux boot. The
first portion of the output comes from Xen itself, supplying low level
-information about itself and the machine it is running on. The
-following portion of the output comes from XenLinux.
+information about itself and the underlying hardware. The last
+portion of the output comes from XenLinux.
You may see some errors during the XenLinux boot. These are not
necessarily anything to worry about --- they may result from kernel
usually use.
When the boot completes, you should be able to log into your system as
-usual. If you are unable to log in to your system running Xen, you
-should still be able to reboot with your normal Linux kernel.
+usual. If you are unable to log in, you should still be able to
+reboot with your normal Linux kernel.
Xen is a \emph{paravirtualising} virtual machine monitor (VMM), or
-`hypervisor', for the x86 processor architecture. Xen can securely
+``hypervisor'', for the x86 processor architecture. Xen can securely
execute multiple virtual machines on a single physical system with
close-to-native performance. The virtual machine technology
facilitates enterprise-grade functionality, including:
\item Virtual machines with performance close to native hardware.
\item Live migration of running virtual machines between physical
hosts.
-\item Excellent hardware support (supports most Linux device drivers).
+\item Excellent hardware support. Supports most Linux device drivers.
\item Sandboxed, re-startable device drivers.
\end{itemize}
space applications and libraries \emph{do not} require modification.
Xen support is available for increasingly many operating systems:
-right now, Linux and NetBSD are available for Xen 2.0.
+right now, Linux and NetBSD are available for Xen 3.0.
A FreeBSD port is undergoing testing and will be incorporated into the
release soon. Other OS ports, including Plan 9, are in progress. We
hope that that arch-xen patches will be incorporated into the
\item [Multiple OS configurations.] Run multiple operating systems
simultaneously, for instance for compatibility or QA purposes.
\item [Server consolidation.] Move multiple servers onto a single
- physical host with performance and fault isolation provided at
+ physical host with performance and fault isolation provided at the
virtual machine boundaries.
\item [Cluster computing.] Management at VM granularity provides more
flexibility than separately managing each physical host, but better
control and isolation than single-system image solutions,
particularly by using live migration for load balancing.
\item [Hardware support for custom OSes.] Allow development of new
- OSes while benefiting from the wide-ranging hardware support of
+ OSes while benefitting from the wide-ranging hardware support of
existing OSes such as Linux.
\end{description}
\section{Structure of a Xen-Based System}
A Xen system has multiple layers, the lowest and most privileged of
-which is Xen itself.
+which is Xen itself.
-Xen in turn may host multiple \emph{guest} operating systems, each of
-which is executed within a secure virtual machine (in Xen terminology,
-a \emph{domain}). Domains are scheduled by Xen to make effective use
-of the available physical CPUs. Each guest OS manages its own
-applications, which includes responsibility for scheduling each
-application within the time allotted to the VM by Xen.
+Xen may host multiple \emph{guest} operating systems, each of which is
+executed within a secure virtual machine. In Xen terminology, a
+\emph{domain}. Domains are scheduled by Xen to make effective use of
+the available physical CPUs. Each guest OS manages its own
+applications. This management includes the responsibility of
+scheduling each application within the time allotted to the VM by Xen.
-The first domain, \emph{domain 0}, is created automatically when the
-system boots and has special management privileges. Domain 0 builds
+The first domain, \emph{domain~0}, is created automatically when the
+system boots and has special management privileges. Domain~0 builds
other domains and manages their virtual devices. It also performs
administrative tasks such as suspending, resuming and migrating other
virtual machines.
-Within domain 0, a process called \emph{xend} runs to manage the
-system. \Xend is responsible for managing virtual machines and
-providing access to their consoles. Commands are issued to \xend over
-an HTTP interface, either from a command-line tool or from a web
+Within domain~0, a process called \emph{xend} runs to manage the
+system. \Xend\ is responsible for managing virtual machines and
+providing access to their consoles. Commands are issued to \xend\
+over an HTTP interface, either from a command-line tool or from a web
browser.
\section{Hardware Support}
Xen currently runs only on the x86 architecture, requiring a `P6' or
-newer processor (e.g. Pentium Pro, Celeron, Pentium II, Pentium III,
-Pentium IV, Xeon, AMD Athlon, AMD Duron). Multiprocessor machines are
-supported, and we also have basic support for HyperThreading (SMT),
+newer processor (e.g.\ Pentium Pro, Celeron, Pentium~II, Pentium~III,
+Pentium~IV, Xeon, AMD~Athlon, AMD~Duron). Multiprocessor machines are
+supported, and there is basic support for HyperThreading (SMT),
although this remains a topic for ongoing research. A port
-specifically for x86/64 is in progress, although Xen already runs on
-such systems in 32-bit legacy mode. In addition a port to the IA64
+specifically for x86/64 is in progress. Xen already runs on such
+systems in 32-bit legacy mode. In addition, a port to the IA64
architecture is approaching completion. We hope to add other
architectures such as PPC and ARM in due course.
Xen can currently use up to 4GB of memory. It is possible for x86
machines to address up to 64GB of physical memory but there are no
-current plans to support these systems: The x86/64 port is the planned
-route to supporting larger memory sizes.
+plans to support these systems: The x86/64 port is the planned route
+to supporting larger memory sizes.
Xen offloads most of the hardware support issues to the guest OS
running in Domain~0. Xen itself contains only the code required to
Xen was originally developed by the Systems Research Group at the
University of Cambridge Computer Laboratory as part of the XenoServers
-project, funded by the UK-EPSRC.
-
-XenoServers aim to provide a `public infrastructure for global
-distributed computing', and Xen plays a key part in that, allowing us
-to efficiently partition a single machine to enable multiple
-independent clients to run their operating systems and applications in
-an environment providing protection, resource isolation and
-accounting. The project web page contains further information along
-with pointers to papers and technical reports:
+project, funded by the UK-EPSRC\@.
+
+XenoServers aim to provide a ``public infrastructure for global
+distributed computing''. Xen plays a key part in that, allowing one to
+efficiently partition a single machine to enable multiple independent
+clients to run their operating systems and applications in an
+environment. This environment provides protection, resource isolation
+and accounting. The project web page contains further information
+along with pointers to papers and technical reports:
\path{http://www.cl.cam.ac.uk/xeno}
-Xen has since grown into a fully-fledged project in its own right,
-enabling us to investigate interesting research issues regarding the
-best techniques for virtualising resources such as the CPU, memory,
-disk and network. The project has been bolstered by support from
-Intel Research Cambridge, and HP Labs, who are now working closely
-with us.
+Xen has grown into a fully-fledged project in its own right, enabling
+us to investigate interesting research issues regarding the best
+techniques for virtualising resources such as the CPU, memory, disk
+and network. The project has been bolstered by support from Intel
+Research Cambridge and HP Labs, who are now working closely with us.
Xen was first described in a paper presented at SOSP in
2003\footnote{\tt
significantly matured and is now used in production scenarios on many
sites.
-Xen 2.0 features greatly enhanced hardware support, configuration
+Xen 3.0 features greatly enhanced hardware support, configuration
flexibility, usability and a larger complement of supported operating
systems. This latest release takes Xen a step closer to becoming the
definitive open source solution for virtualisation.
a starting point:
\begin{itemize}
\item \path{/etc/xen/xmexample1} is a simple template configuration
- file for describing a single VM.
-
+ file for describing a single VM\@.
\item \path{/etc/xen/xmexample2} file is a template description that
is intended to be reused for multiple virtual machines. Setting the
value of the \path{vmid} variable on the \path{xm} command line
\begin{quote}
\begin{description}
\item[kernel] Set this to the path of the kernel you compiled for use
- with Xen (e.g.\ \path{kernel = `/boot/vmlinuz-2.6-xenU'})
+ with Xen (e.g.\ \path{kernel = ``/boot/vmlinuz-2.6-xenU''})
\item[memory] Set this to the size of the domain's memory in megabytes
(e.g.\ \path{memory = 64})
\item[disk] Set the first entry in this list to calculate the offset
- of the domain's root partition, based on the domain ID. Set the
+ of the domain's root partition, based on the domain ID\@. Set the
second to the location of \path{/usr} if you are sharing it between
- domains (e.g.\ \path{disk = [`phy:your\_hard\_drive\%d,sda1,w' \%
+ domains (e.g.\ \path{disk = ['phy:your\_hard\_drive\%d,sda1,w' \%
(base\_partition\_number + vmid),
- `phy:your\_usr\_partition,sda6,r' ]}
+ 'phy:your\_usr\_partition,sda6,r' ]}
\item[dhcp] Uncomment the dhcp variable, so that the domain will
- receive its IP address from a DHCP server (e.g.\ \path{dhcp=`dhcp'})
+ receive its IP address from a DHCP server (e.g.\ \path{dhcp=``dhcp''})
\end{description}
\end{quote}
the MAC address of the virtual ethernet interface yourself. For
example:
\begin{quote}
-\verb_vif = [`mac=00:06:AA:F6:BB:B3']_
+\verb_vif = ['mac=00:06:AA:F6:BB:B3']_
\end{quote}
If you do not set this variable, \xend\ will automatically generate a
random MAC address from an unused range.
section of the project's SourceForge site (see
\path{http://sf.net/projects/xen/}).
\item Create a configuration file like the following:
+ \begin{quote}
\begin{verbatim}
kernel = "/boot/vmlinuz-2.6-xenU"
memory = 64
ip = "1.2.3.4"
disk = ['file:/path/to/ttylinux/rootfs,sda1,w']
root = "/dev/sda1 ro"
-\end{verbatim}
+\end{verbatim}
+ \end{quote}
\item Now start the domain and connect to its console:
+ \begin{quote}
\begin{verbatim}
xm create configfile -c
\end{verbatim}
+ \end{quote}
\item Login as root, password root.
\end{enumerate}
projects / xen.git / commitdiff